REMARKS 



Claims 27 and 28 have been amended to recite a tangible computer accessible 
medium, rather than a carrier medium. No claims have been added or cancelled. Claims 
1-28 remain pending in the application. Reconsideration is respectfully requested in Hght 
of the following remarks. 

Section 103(a) Reiection : 

The Examiner rejected claims 1-7, 14-20 and 27 under 35 U.S.C. § 103(a) as 
being unpatentable over Juster et al. (U.S. Patent 6,202,089) (hereinafter "Juster") in 
view of Stem et al. (U.S. Patent 5,935,249) (hereinafter "Stem"). Applicants respectfiiUy 
traverse the rejection of claims 1-7, 14-20 and 27 for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, Juster in view of Stem 
fails to teach receiving an address for a service within the distributed computing 
environment; linking the address to a pre- generated message interface for accessing the 
service, wherein the message interface comprises computer-executable code built into the 
device , and wherein the linking creates a message endpoint for the device to send 
messages to the service at the address in order to access the service; and using the 
message endpoint to send messages to the address to access the service. 

Juster teaches a method for configuring, identifying and using a plurality of 
remote procedure call (RPC) endpoints in a single server process. Specifically, Juster 
teaches a server process that establishes a plurality of RPC endpoints and a separate RPC 
endpoint for responding to address queries fi*om clients. According to Juster, a client first 
places a remote procedure call to the address request RPC endpoint of the server process 
that returns the address of another RPC endpoint providing a service desired by the client 
(Juster, Abstract, column 2, lines 3-26). 
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Contrary to the Examiner's contention, Juster in view of Stem fails to teach 
receiving an address for a service within the distributed computing environment and 
Unking the address to a pre-generated message interface for accessing the service . The 
Examiner cites the Abstract, Figures 2A, 2B, and column 2, lines 3-26 and column 7- 
lines 10-31 of Juster. However, none of the cited portions of Juster disclose linking a 
received address to a pre-generated message interface for accessing the service. Instead, 
Juster teaches that a client queries the server via the server's address request RFC 
endpoint to obtain the address of a RFC endpoint that provides a desired service (Juster, 
column 2, lines 18-23, column 4, lines 55-52, and column 7, lines 10-31). Once the client 
obtains the address, Juster states only that the client performs remote procedure calls on 
the server RFC endpoint using the received address (Juster, Figure 5, step 525, column 2, 
lines 23-25, and column 4, lines 62-64). Juster does not mention a client linking the 
address received from the server to a pre-generated message interface for accessing the 
service. In fact, Juster is completely silent regarding how a client performs remote 
procedure calls because Juster is not concerned with how a client performs remote 
procedure calls. Instead, Juster deals only with configuring multiple server RFC 
endpoints for a single server process. 

Traditional remote procedure call (RFC) systems, such as those mentioned by 
both Juster and Stem, utilize one of two different client-side RFC mechanisms. In some 
traditional RFC systems, a client wishing to communicate with a remote server locates 
and downloads a stub object that is configured to communicate with the remote server 
object (or process). The client then executes methods of the stub object that 
communicates the necessary method parameters and return values between the client and 
the remote object. In other traditional RFC systems, the client repeatedly calls a standard 
RFC library routine, passing in the remote RFC endpoint address and any necessary 
parameters. The client calls the same routine to execute RFC calls on different remote 
server objects, passing in the relevant address each time. Conventional RFC 
mechanisms, such as described in Juster and Stem do not link an address to a pre- 
generated message interface for accessing a service, wherein the message interface 
comprises computer-executable code built in to the device. 
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In further regard to claim 1, Juster in view of Stem also fails to teach linking said 
address to a pre-generated message interface for accessing said service, wherein the 
message interface comprises computer-executable code built into the device . The 
Examiner admits that Juster fails to teach a pre-generated message interface comprising 
computer-executable code built into the device and relies upon Stem, citing the Title, 
Figures 4, 6, 7, and 9, as well as column 4, lines 1-14 and column 8, lines 27-59 of Stem. 
However, none of the cited portions of Stem disclose a pre-generated message interface 
comprising computer-executable code built into the device. Instead, the Title only refers 
to a mechanism for embedding network based control systems in a local network 
interface device. Figures 4, 6, 7, and 9 illustrate various networked computer devices, 
none of which include a pre-generated message interface comprising computer- 
executable code built into the device. Column 4, lines 1-14 of Stem only describe an 
exemplary computer system that may load and execute instructions, either from a 
persistent store, or downloaded over the network. Column 8, lines 27-59 of Stem 
describes the use of Java and a Java Virtual Machine in Stem's Java Enabled Network 
Interface Device. Thus, none of the Examiner's cited portions of Stem disclose or 
mention anything regarding a pre-generated message interface comprising computer- 
executable code built into the device. 

Thus, Juster in view of Stem fails to teach or suggest receiving an address for a 
service within a distributed computing environment and linking the address to a pre- 
generated message interface for accessing the service, wherein the message interface 
comprises computer-executable code built into the device. 

In response to the above argument, the Examiner, in the Response to Arguments, 
states, "Juster is relied upon to disclose the linking feature and Stem disclosed the pre- 
generated message interface feature" and cites a portion of the Abstract of Juster. 
Specifically, the Examiner argues, "the process of establishing an RFC endpoint portal 
for accessing a service reads on linking an address to an interface for accessing a service. 
However, contrary to the Examiner's assertion, Juster does not mention or suggest a 
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client establishing an RPC endpoint portal. Instead, as noted above, Juster merely 
states that a client places an remote procedure call to a server endpoint. Furthermore, as 
described above, traditional remote procedure call mechanisms, such as those mentioned 
by both Juster and Stem, do not involve linking a received address to a pre-generated 
message interface for accessing the service, wherein the message interface comprises 
computer-executable code built in to said device. 

The Examiner further responds to applicants arguments by referring to Stem's use 
of a "Java Enabled Network Interface Device having executable instruction built into the 
embedded interface of the device" and additionally cites colunm 2, lines 59-67 of Stem. 
Column 2, lines 59-67 of Stem describes how Stem's secure language processor, which 
is implemented with a Java language interpreter, provides control over embedded non- 
volatile memory for storing objects of value and a restricted interface and how "this 
mechanism allows a network interface device to represent and proxy for services 
available on a network, even when the local device is disconnected fi:om the network." 
However, neither this passage nor any other passage of Stern mentions a pre- 
generated message interface. As described above, the other portions of Stem cited by 
the Examiner fail to mention a pre-generated message interface comprising computer- 
executable code built into the device. Instead, the cited portions of Stem only refer 
generally to how computer instmctions are loaded and executed and how Stem uses a 
Java Virtual Machine. Stem is completely silent regarding a pre-generated message 
interface for accessing a service including computer-executable code built into the 
device. Merely mentioning that a device may "represent and proxy for services" does not 
imply any pre-generated message interface for accessing a service. Stem is referring to 
the ability to locally store objects, such as a server proxy object, that are normally stored 
on remote network devices. Stem is not referring to any sort of pre-generated message 
interface. Furthermore, column 4, lines 5-14, where Stem describes how instmctions are 
downloaded and executed on a network interface device, also fails to mention anything 
regarding a pre-generated message interface for accessing a service. Without some clear 
teaching by Stem regarding a pre-generated message interface for access a service, the 
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Examiner's argument amounts to nothing more than speculation regarding the workings 
of Stem's system. 

Furthermore, Juster in view of Stem further fails to teach linking an address to a 
pre-generated message interface for accessing the service, wherein said linking creates a 
message endpoint for the device to send messages to the service at the address in order to 
access the service, contrary to the Examiner's assertion. As noted above, Juster fails to 
disclose anything regarding how a client makes remote procedure calls after obtaining an 
address for one of the server's RPC endpoints. In fact, Juster only states, "the client then 
places a remote procedure call on the desired endpoint of the server process," without 
providing any fiirther information regarding how a client may use one of the server's 
RPC endpoint addresses to make a remote procedure call (Juster, column 2, lines 23-26). 

None of the Examiner's cited portions of Juster (Abstract, Figures 2A, 2B, and 
column 2, lines 3-26 and column 7-lines 10-31) mention anything regarding linking of an 
address creating a message endpoint for the device to send messages to the service at the 
address in order to access the service. Instead, the portions cited by the Examiner only 
provide an overview of Juster' s invention, which, as noted above, deals wdth configuring 
multiple RPC endpoints for a server process, but does not disclose anything about 
creating a message endpoint for the device to send messages to the service at the address 
in order to access the service (Abstract, Figures 2A and 2B, and column 2, lines 3-26). 
The Examiner also cited a passage where Juster describes how a service responds to a 
client address query by determining an appropriate RPC endpoint and providing an 
address to that RPC endpoint to the requesting client (column 7, lines 10-31). However, 
as noted above, Juster does not describe, or even mention, how a client uses the provided 
address except to say that the client performs remote procedure calls on the server RPC 
endpoint using the received address (Juster, Figure 5, step 525, column 2, hnes 23-25, 
and column 4, lines 62-64). Juster mentions nothing of linking a received address to a 
pre-generated message interface. Additionally, Stem does not overcome any of the 
deficiencies of Juster regarding linking an address to a pre-generated message interface 
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creates a message endpoint for the device to send messages to the service at the address 
in order to access the service. 

The combination of Juster and Stem suggested by the Examiner would only result 
in a system including a server process that establishes multiple RPC endpoints, including 
an address query endpoint, and that also includes a Java Enabled Network Interface 
Device as taught by Stem. Since neither Juster nor Stem, alone or in combination, teach 
or suggest linking an address to a pre- generated message interface for accessing the 
service, wherein the message interface comprises computer-executable code built in to 
the device , and wherein the linking creates a message endpoint for the device to send 
messages to the service at the address in order to access the service, the rejection is 
unsupported by the cited art. 

Thus, in light of the above remarks. Applicants assert that the rejection of claim 1 
is not supported by the cited prior art and its withdrawal is respectfully requested. 
Similar remarks as discussed above regarding claim 1, also apply to claims 14 and 27. 

Regarding claim 2, contrary to the Examiner's assertion, Juster in view of Stem 
fails to teach the message interface of the message endpoint verifving that the messages 
sent to the service complv with a message schema for the service. The Examiner cites 
portions of Juster (Abstract, Figures 2A and 2B, and column 2, lines 3-26). However, 
none of the cited portions of Juster teach or disclose a message interface of a message 
endpoint verifying that messages sent to a service comply with a message schema for the 
service. Instead, as noted above regarding the rejection of claim 1, Juster only states that 
the client performs remote procedure calls on the server RPC endpoint using the received 
address (Juster, Figure 5, step 525, column 2, lines 23-25, and column 4, lines 62-64). 
Juster does not mention anything regarding a message schema for the service, nor about 
any sort of message interface verifying that messages sent to a service comply with a 
message schema for the service. Additionally, the Examiner has failed to point out or 
cite any portion of either Juster or Stem that describes a message interface verifying that 
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messages sent to a service comply with a message schema for the service. As noted 
above regarding claim 1, Juster is not concemed with how a client access a service, 
except that a client first contacts a service via an address query RPC endpoint to obtain an 
address to a RPC endpoint providing a specific service. Juster does not teach, nor does 
luster's system include, any sort of message interface verifying that messages sent to a 
service comply with a message schema for the service. As with claim 1, above. Stem 
fails to overcome any of luster's deficiencies regarding the Examiner's rejection of claim 
2. 

Applicants note that the Examiner has failed to provide any rebuttal to the 
above arguments in regard to claim 2. Thus, for at least the reasons above, the 
rejection of claim 2 is not supported by the prior art and its removal is respectfully 
requested. Similar remarks as discussed above in regard to claim 2, apply to claim 15. 

In regard to claim 3, contrary to the Examiner's assertion, Juster in view of Stem 
fails to teach wherein the message schema defines messages to be sent to a nd received 
from the service , wherein the messages are defined in a data representation language . 
The Examiner cites column 9, lines 3-47 of Stem. However, the portion of Stem cited by 
the Examiner does not describe any message schema defining messages to be sent to and 
received fi-om a service and further does not teach that the messages are defined in a data 
representation language, histead, column 9, lines 3-47 of Stem, describe how Stem's 
system allows for a Java Virtual Machine to securely store an object of value, such as a 
software license or other software key controlling the use of an application. The 
Examiner's cited portion of Stem also describes how his Java Enabled Network Interface 
may be treated as a tmsted device for the purposes of reloading items of value, such as 
for resetting the number of uses permitted by a software license. A Java Enabled 
Network Interface securely storing security objects and Stem's other objects of value, 
does not disclose a message schema defining messages to be sent to and received fi^om a 
service, nor does it teach that such messages may are defined in a data representation 
language. Stem does not teach, in the Examiner's cited passage or elsewhere, a message 
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schema defining messages to be sent to and received from a service, and wherein the 
messages are defined in a data representation language. 

Therefore, the Examiner's proposed combination of Juster in view of Stern also 
fails to teach wherein the message schema defines messages to be sent to and received 
from the service , wherein the messages are defined in a data representation language . 
Additionally, the arguments presented above regarding claim 2 apply to claim 3, as well. 
Thus, for at least the reasons above, the rejection of claim 3 is not supported by the prior 
art and its removal is respectfiiUy requested. Similar remarks as discussed above in 
regard to claim 3, apply to claim 16. 

Applicants also note that the Examiner has failed to provide any rebuttal to 
the above arguments in regard to claim 3. 

Regarding claim 4, Juster in view of Stem fails to teach wherein the data 
representation language is extensible Markup Language , as asserted by the Examiner. 
The Examiner cites column 9, lines 3-47 of Stem. However, the portion of Stem cited by 
the Examiner does not describe any message schema defining messages to be sent to and 
received from a service, wherein the messages are defined in a data representation 
language; and wherein the data representation language is extensible Markup Language . 
Instead, column 9, lines 3-47 of Stem, describe how Stem's system allows for a Java 
Virtual Machine to provide secure storage of an object of value, such as a software 
license or other software key controlling the use of an application. The Examiner's cited 
portion of Stem also describes how a Java Virtual Machine may be treated as a trusted 
device for the purposes of reloading items of value, such as for resetting the number of 
uses permitted by a software license. The cited passages have nothing to do with a 
message schema defining messages to be sent to and received from a service; wherein the 
messages are defined in a data representation language, and wherein the data 
representation language is extensible Markup Language. In fact, Stem does not teach, in 
the Examiner's cited passage or elsewhere, anything regarding messages defined in a data 
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representation language and wherein the data representation language is extensible 
Markup Language. 

Thus, the combination of Juster in view of Stem, as suggested by the Examiner, 
fails to teach wherein the data representation language is extensible Markup Language . 
Additionally, the arguments presented above regarding claim 3 apply to claim 4, as well. 
Thus, for at least the reasons above, the rejection of claim 4 is not supported by the prior 
art and its removal is respectfully requested. Similar remarks as discussed above in 
regard to claim 4, apply to claim 17. 

Applicants also note that the Examiner has failed to provide any rebuttal to 
the above arguments in regard to claim 4. 

Li regard to claim 5, contrary to the Examiner assertion, Juster in view of Stem 
fails to teach receiving an authentication credential indicating authorization to access the 
service; and wherein said linking comprises linking the authentication credential to the 
pre- generated message interface , wherein the message endpoint is configured to include 
the authentication credential with each message to the address for a service in a 
distributed computing environment. 

The Examiner cites portions of both Juster and Stem, without providing any 
reasons or discussion regarding how the Examiner is combining the teachings of Juster 
and Stem. The Examiner cites the Abstract, Figures 2A and 2B, and column 2, lines 4-26 
of Juster and the Abstract, Figures 6 and 7, column 9, lines 3-25, column 12, lines 13-49 
and column 13, hnes 25-42 of Stem. However, none of the Examiner's cited portions of 
either Juster or Stem describes receiving an authentication credential indicated 
authorization to assess the service, linking the authentication credential to the pre- 
generated message interface, wherein the message endpoint is configured to include the 
authentication credential with each message sent to the address. 
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Instead, the cited portions of luster teach that a client queries the server via the 
server's address request RPC endpoint to obtain the address of a RPC endpoint that 
provides a desired service (Juster, column 2, lines 18-23, column 4, lines 55-52, and 
column 7, lines 10-31). Once the cUent obtains the address, Juster only states that the 
client performs remote procedure calls on the server RPC endpoint using the received 
address (Juster, Figure 5, step 525, column 2, lines 23-25, and column 4, lines 62-64). 
The cited portions of Stem only refer to Stem's network interface device that stored 
identification keys for remote devices and object of value for network applications and 
that verify that a host computer is authorized to execute certain controlled applications. 

The cited portions of Stem also fail to teach anything regarding linking an 
authentication credential to a pre-generated message, wherein the message endpoint is 
configured to include the authentication credential with each message sent to the address 
for a service in a distributed computing environment. Specifically, the Abstract and 
figures 6 and 7 of Stem provide an overview of Stem's secure, trusted network 
management function embedded within a Java enabled network interface device. 
Column 9, lines 3-25 describe how Stem's system allows for a Java Virtual Machine to 
provide secure storage of an object of value, such as a software license or other software 
key controlling the use of an application and how a Java Virtual Machine may be treated 
as a trusted device for the purposes of reloading items of value, such as for resetting the 
number of uses permitted by a software license. Column 12, lines 13-49 of Stem 
describe how Stem's Java Enabled Network Interface Device may securely store digital 
signature objects while preventing unauthorized access or tampering of the stored secured 
objects. Additionally, column 13, lines 25-42 of Stem describe how Stem's system 
includes the capability of storing cryptographic keys for multiple users of a host 
computer allowing those users to "authenticate themselves without requiring additional 
hardware" (Stem, column 13, lines 30-34). 

Thus, neither Juster nor Stem, singly or in combination, at the Examiner's cited 
portions or elsewhere, teach anything to do with linking an authentication credential, 
indicating authorization to access a service, to a pre-generated message interface, wherein 
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the message endpoint is configured to include the authentication credential with each 
message sent to the address for a service in a distributed computing environment, as 
asserted by the Examiner. 

Therefore, in light of the above remarks, applicants assert that the rejection of 
claim 5 is not supported by the cited art and withdraw^al of the rejection is respectfully 
requested. Similar remarks as discussed above in regard to claim 5 apply to claim 1 8 as 
well. 

Applicants also note that the Examiner has failed to provide any rebuttal to 
the above arguments in regard to claim 5. 

Regarding claim 6, contrary to the Examiner's contention, Juster in view of Stem 
fails to teach locating a service advertisement for the service, wherein the service 
advertisement indicates an authentication service; requesting the authentication credential 
fi-om the authentication service to assess the service; and wherein said receiving an 
authentication credential comprises receiving the authentication credential fi'om the 
authentication service. The Examiner relies upon Stem and cites the Abstract, column 4, 
lines 1-14, column 9„lines 3-25, and column 10, lines 29-67. However, none of the cited 
passages of Stem teach anything regarding locating a service advertisement that indicates 
an authentication service, about requesting a authentication credential firom the 
authentication service to access the service, or about receiving an authentication 
credential fi'om the authentication service. Instead, the Examiner has cited portions that 
provide an overview of Stem's secure, trusted network management function embedded 
within a Java enabled network interface device (Abstract, and column 4, lines 1-14). 
Column 9, lines 3-25 of Stem describe how Stem's system allows for a Java Virtual 
Machine to provide secure storage of an object of value, such as a software license or 
other software key controlling the use of an application and how a Java Virtual Machine 
may be treated as a trusted device for the purposes of reloading items of value, such as 
for resetting the nimiber of uses permitted by a software license. Column 10, lines 29-67 
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describe how Stern's system allows for the storing of data, such as security objects, into 
flash memory, "so that they will remain in place after a power cycle or machine reboot." 

Thus, the combination of Juster in view of Stem suggested by the Examiner fails 
to teach locating a service advertisement for a service, wherein the service advertisement 
indicated an authentication service; requesting an authentication credential from the 
authentication service to access the service; and receiving the authentication credential 
from the authentication service. For at least the reasons presented above, the rejection of 
claim 6 is not supported by the cited art and withdrawal of the rejection is respectfiiUy 
requested. Similar remarks as discussed above in regard to claim 6 apply to claim 19 as 
well. 

Applicants also note that the Examiner has failed to provide any rebuttal to 
the above arguments in regard to claim 4. 

In regard to claim 7, Juster in view of Stem does not teach or suggest locating a 
service advertisement for a service, wherein the service advertisement comprises the 
address for the service and indicates a message schema for the service; wherein said 
receiving an address comprises receiving the address from the service advertisement; and 
wherein said linking comprises verifying that the pre-generated message interface 
corresponds to the message schema. The Examiner cites portions of both Juster and 
Stem, but none of the cited portions mentions anything regarding locating a service 
advertisement comprising an address for a service and that indicates a message schema 
for the service. The cited portions also fail to teach anything regarding receiving the 
address for the service from the service advertisement or regarding verifying that a pre- 
generated message interface corresponds to the message schema. 

Instead, the cited portions of Juster teach that a client queries the server via the 
server's address request RPC endpoint to obtain the address of a RFC endpoint that 
provides a desired service (Juster, column 2, lines 18-23, column 4, lines 55-52, and 
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column 7, lines 10-31). Once the client obtains the address, Juster only states that the 
client performs remote procedure calls on the server RPC endpoint using the received 
address (Juster, Figure 5, step 525, column 2, lines 23-25, and column 4, lines 62-64). 
The Abstract and figures 6 and 7 of Stem provide an overview of Stem's secure, trusted 
netv^ork management function embedded within a Java enabled network interface device. 
Column 9, lines 3-25 describe how Stem's system allows for a Java Virtual Machine to 
provide secure storage of an object of value, such as . a software license or other software 
key controlling the use of an application and how a Java Virtual Machine may be treated 
as a trusted device for the purposes of reloading items of value, such as for resetting the 
number of uses permitted by a software license. Column 12, lines 13-49 of Stem 
describe how Stem's Java Enabled Network Interface Device may securely store digital 
signature objects while preventing unauthorized access or tampering of the stored secured 
objects. Additionally, column 13, lines 25-42 of Stem describe how Stem's system 
includes the capability of storing cryptographic keys for multiple users of a host 
computer allowing those users to "authenticate themselves v^thout requiring additional 
hardware" (Stem, column 13, lines 30-34). 

Thus, the Examiner's combination of Juster in view of Stem fails to teach locating 
a service advertisement for a service, wherein the service advertisement comprises the 
address for the service and indicates a message schema for the service; wherein said 
receiving an address comprises receiving the address fi*om the service advertisement; and 
wherein said linking comprises verifying that the pre-generated message interface 
corresponds to the message schema. Additionally, the arguments presented above 
regarding claim 1 also apply to claim 7. 

Thus, for at least the reasons discussed above, the rejection of claim 7 is not 
supported by the prior art and removal thereof is respectfiiUy requested. Similar remarks 
to those discussed above regarding claim 7 also apply to claim 20. 

Applicants also note that the Examiner has failed to provide any rebuttal to 
the above arguments in regard to claim 4. 
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The Office Action rejected claims 8-13, 21-26 and 28 under 35 U.S.C. § 103(a) as 
being unpatentable over Hind, et al. (U.S. Patent 6,585,778) (hereinafter "Hind") in view 
of Lee, et al. (U.S. Patent 6,336,137) (hereinafter "Lee"). Applicants respectfiilly traverse 
the rejection of claims 8-13, 21-26 and 28 for at least the following reasons. 

Regarding claim 8, contrary to the Examiner's assertion Hind in view of Lee fails 
to disclose a method for accessing services, comprising: receiving a schema defining 
messages for accessing the service ; generating message endpoint code accord ing to said 
schema . 

Hind teaches a system for data policy enforcement using style sheet processing 
wherein a Document Type Definitions (DTD) including stored policy enforcement 
objects is applied to an input document representing a response to a user request. In the 
Examiner' cited passages (Abstract, column 4, lines 16-32, lines 50-59, and column 7, 
lines 9-18) Hind describes how a DTD corresponding to the input document may include 
references to stored policy enforcement objects that each enforce a data policy for an 
element of the input document and that each referenced stored policy object is 
instantiated and applied to the input document to create an output docxmient matching the 
enforced data policies (Hind, column 4, lines 16-32). Hind fiirther teaches that executing 
selected ones of the instantiated pohcy enforcement objects may also involve considering 
a target context of a user and may also involve determining whether an output DTD 
element will be created for an element of the input document (Hind column 4, lines 50- 
59). The last cited passage describes how Hind's invention may be implemented as a 
software program running on an intermediary of a network or as individual modules 
invoked upon request (Hind, column 7, lines 9-18). 

None of the cited passages describe receiving a schema defining messages for 
accessing a service. In contrast, Hind teaches a system that enforces data policy on 
retrieved documents (resulting fi-om user requests). Hind fails to teach anything 
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regarding schemas that define messages for accessing services. Instead Hind deals with 
data documents that result fi-om user requests. 

Hind also fails, contrary to the Examiner's contention, to teach generating 
message endpoint code according to the schema . Hind teaches the loading and executing 
of data policy objects that are referenced in a DTD defining data policies to be enforced 
on an input document representing a response to a user request. Such data policy objects 
are not message endpoint code, but instead are style sheets that translate, transform, or 
tailor the information of input documents before they are delivered to particular devices 
(Hind, column 7, lines 29-49, column 8, lines 38-57). Style sheet processing and data 
transformation is not the generation of message endpoint code according to a schema 
defining messages for accessing a service. 

In response to the above arguments, the Examiner, in the Response to Arguments 
section of the Final Office Action, states "Hind disclosed the use of template 
representation for accessing [a] service in a v^ireless system and the generating of [an] 
endpoint to establish communication path between the wireless device and the wireless 
service provider." However, the Examiner fails to cite any additional portion of Hind 
and further fails to rebut any of Applicants arguments regarding the portions of 
Hind cited by the Examiner. Additionally, the Examiner argument fails to point out 
any portion of Hind that teaches or suggests generating message endpoint code 
according to a received schema defining messages for accessing a service. As noted 
above, Hind teaches uses DTDs to transform input documents to output documents. 

The Examiner admits that Hind does not teach linking said message endpoint 
code into executable operating code for the device and loading the message endpoint 
code and operating code onto the device and contends that Lee teaches such fimctionality. 
However, Lee discloses a method for transferring data via a network between a server 
and clients or browsers that are spatially distributed wherein a server parses client 
requests to determine both the language of the request and the information requested. 
The server also associates various markup languages with different virtual directories and 
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clients that want to request a particular markup language can route their requests to the 
appropriate directory. (Lee, Abstract, column 4, lines 13-34). Lee fails to teach linking 
generated message endpoint code into executable operating code for the device and 
loading the message endpoint code and operating code onto the device. 

The Examiner cites two passages of Lee in support of his arguments. The first 
passage describes how a client may be an HTTP client and also a gateway server to 
wireless browser clients that request pages fi-om the client via WAP protocol that the 
gateway server transforms into HTTPAVML requests that are submitted to the main 
server. Such a gateway server also transforms the responses back into WAPAVML 
responses to be returned to the wireless clients (Lee, column 9, lines 21-45). The second 
passage cited by the Examiner describes a web engine that interprets a WML template 
containing embedded tags regarding what data the engine should retrieve fi'om an 
associated database. The web engine then generates new WML code segments with the 
requested data and replaces the tags in the original WML template with the new code and 
sends the completed WML file to a WML browser (Lee, column 12, lines 22-38). 
Applicants can find no relevance in the Examiner's cited passages to linking generated 
message endpoint code into executable operating code for a device and loading the 
massage endpoint code and operating code onto the device. In contrast, Lee is teaching 
the use of specialized SWE tags for building custom data responses in a chent requested 
mark up language. Lee fails to teach anything regarding any type of linking or loading of 
message endpoint code. 

Hind and Lee, separately and in combination, fail to teach or suggest receiving a 
schema defining messages for accessing a service; generating message endpoint code 
according to the schema; and linking the message endpoint code into executable 
operating code for the device and loading the message endpoint code and operating code 
onto the device. 

Therefore, in light of the above remarks, applicants assert that the rejection of 
claim 8 is not supported by the cited art and withdrawal of the rejection is respectfiiUy 
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requested. Similar remarks as discussed above in regard to claim 8 apply to claims 21 
and 28. 



Regarding claim 9, contrary to the Examiner's contention, Hind in view of Lee 
fails to disclose a method wherein said message endpoint is configured to verify that the 
messages sent fi'om the device to the service comply with the schema . The Examiner 
cited two passages of Lee. The first (Lee, column 5, lines 26-50) describes Lee's client- 
server method where the server is configured to receive requests fi'om and send responses 
to the client. The server is also configured to determine the language, protocol or syntax 
in the client requests and to interpret the request to determine the data submitted by the 
client. The system then recovers metadata or descriptive information firom a metadata 
repository and creates a response in the client's preferred language, protocol, and/or 
syntax. Lee's system also includes the capability for interpreting the client request to 
determine classes or instances of business objects and user data to associate with the 
request and to determine data submitted by the client regarding creating, modifying, 
deleting, or appending such business objects. The second cited passage (Lee, column 7, 
lines 10-24) describes how, imder Lee, the metadata may have different representations 
according to the client's preferred language, protocol, or syntax and how the server is 
configured to represent such metadata using the client's preferences. Thus, rather than 
teaching verifying that messages sent fi"om a device to a service comply with a schema, 
Lee clearly teaches examining a received message to determine the language, protocol 
and syntax used in the message. 

Neither of the Examiner's cited passages have any relevance to a message 
endpoint configured to verify that messages sent fi'om a device to a service comply with a 
schema defining messages for accessing the service. In contrast, Lee teaches that a server 
determines a client's preferred language, protocol, and/or syntax and ensures that 
responses are appropriate for the client according to the client's preferred language, 
protocol, or syntax. Applicants also fail to see how Lee's title, "Web Client-Server 
System and Method for Incompatible Page Markup and Presentation Languages," as cited 
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by the Examiner, is relevant to the Examiner's argument. None of these teachings in Lee 
have anything to do with a message endpoint being configured to verify that messages 
sent from the device to the service comply with a schema. 

In response to the above arguments, the Examiner states merely, "Lee disclosed a 
method wherein token messages are used to verify repository of templates that are 
configured for the specific language or protocol utilized by the client." However, the 
Examiner is referring to using messages to verify a repository of templates not 
verifying tliat messages sent from a device to a service comply with a schema 
defining messages for accessing the service. Verifying a repository of templates 
using message does not teach or suggest verifying that messages sent from a device 
to a service comply with a schema. 

Thus, the combination of Hind in view of Lee, as suggested by the Examiner, fails 
to teach wherein the message endpoint is configured to verify that messages sent from the 
device to the service comply with the schema. Furthermore, the Examiner has failed to 
provide any specific response to applicants' arguments when previously presented. 

Therefore, in Ught of the above remarks, applicants assert that the rejection of 
claim 9 is not supported by the cited art and withdrawal of the rejection is respectfiilly 
requested. Similar remarks as discussed above in regard to claim 9 apply to claim 22. 

Regarding claim 10, Hind in view of Lee fails to teach a method wherein said 
schema defines messages to be sent to and received from the service wherein said 
messages are defined in a data representation language . In contrast. Hind teaches that 
intermediaries in his system apply various types of translation and/or transformations 
based upon target (client) context, giving the transformation of a response from XML to 
another data markup language as an example (Hind, column 7, lines 19-33). Hind also 
teaches how a DTD, as a definition of an XML docvunent, tell a parser how to interpret 
the XML document, such as by defining entries for title, author, retail price, cost and 
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quantity of a book, in one example (Hind, column 9, lines 27-35). Hind is describing 
various data translations and transformations on response documents in order to enforce 
specific data policies. Neither Hind nor Lee, separately or in combination, describes a 
schema that defines message in a data representation to be sent to and received fi-om a 
service. Furthermore, the Examiner has failed to provide any specific response to 
applicants' arguments in regard to claim 10. 

In light of the above remarks, the rejection of claim 10 is not supported by the 
cited art and v^ithdrawal of the rejection is respectfully requested. Similar remarks as 
discussed above in regard to claim 10 apply to claim 23. 

Applicants also assert that numerous other ones of the dependent claims recite 
further distinctions over the cited art. However, since the rejection has been shown to be 
unsupported for the independent claims, a further discussion of the dependent claims is 
not necessary at this time. 

Information Disclosure Statement : 

Applicants note that an information disclosure statement with accompanying 
Forms PTO-1449 was mailed on February 8, 2005. Applicants have not yet received the 
signed and initialed copy of the Form PTO-1449 fi-om this statement. Applicants request 
the Examiner to carefully consider the listed references and return a copy of the signed 
and initialed Forms PTO-1449 fi"om this statement (a copy of which is enclosed herewith 
for the Examiner's convenience). 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and notice to that 
effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5181- 
66200/RCK. 

Also enclosed herewith are the following items: 
^ Return Receipt Postcard 
I I Petition for Extension of Time 
I I Notice of Change of Address 
^ Copy of previously submitted form PTO-1449 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: July 28. 2005 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 
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